Pull request overview

This PR adds comprehensive support for BPF map-of-maps (BPF_MAP_TYPE_HASH_OF_MAPS and BPF_MAP_TYPE_ARRAY_OF_MAPS) to the Aya framework, building upon the foundation from PR #70.

Changes:

• Added inner attribute to #[map] macro for declaring map-of-maps templates in eBPF code
• Implemented HashMapOfMaps and ArrayOfMaps types with get(), iter(), and other helper methods
• Added support for program array population via EbpfLoader::set_prog_array_entry() and Ebpf::populate_prog_arrays()

Reviewed changes

Copilot reviewed 43 out of 43 changed files in this pull request and generated no comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f2593b39d1

@tamird made 3 comments.
Reviewable status: 0 of 43 files reviewed, 3 unresolved discussions (waiting on @Brskt).

-- commits line 70 at r35:
The commits in this PR are mostly a mess, but e.g. this one looks useful on its own. Did you intend for the commits history to be preserved? If yes, we will need you to rewrite it into something coherent. If not, then this PR is 3k lines that have to be reviewed in one shot, which is quite difficult.

Code quote:

New commits in r8 on 1/17/2026 at 4:21 PM:
- d1f0cb8: feat(aya): Add prog_array population support for tail calls

  Add EbpfLoader::set_prog_array_entry() to declaratively specify which
  programs should be placed in program arrays at which indices.

  Add Ebpf::populate_prog_arrays() to populate the declared entries with
  loaded program file descriptors after programs are loaded.

  This enables easier setup of tail call jump tables without manually
  managing program array entries.

@Brskt made 3 comments and resolved 2 discussions.
Reviewable status: 0 of 43 files reviewed, 1 unresolved discussion (waiting on @tamird).

-- commits line 70 at r35:

Yes, I've kept the commit history and rewritten it as requested:

1. aya-ebpf: eBPF-side map-of-maps implementation
2. aya-ebpf-macros: inner attribute for #[map] macro
3. aya-obj: Map constructors and .maps.inner parsing
4. aya: userspace map-of-maps support
5. tests: integration and unit tests
6. public API updates

Should be easier to review now.

@tamird partially reviewed 15 files and made 2 comments.
Reviewable status: 1 of 43 files reviewed, 2 unresolved discussions (waiting on @Brskt).

-- commits line 70 at r35:

it's still just one big blob, right? the commits are now cut along which crates they touch, which is maybe easier for review but they need to be squashed on merge. do I understand correctly?

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

///
/// Only implement this trait for map types that can be safely used as inner maps.
pub unsafe trait InnerMap {}

🤔 does this need to be pub?

@Brskt made 2 comments.
Reviewable status: 1 of 43 files reviewed, 2 unresolved discussions (waiting on @tamird).

-- commits line 70 at r35:

Yes, that's correct. Split for easier review, feel free to squash on merge.

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

I tested with pub(crate) and here's what happens:

Build results:

• cargo build: ⚠️ 3 warnings (private_bounds)
• cargo clippy -D warnings: ❌ 3 errors - fails CI
• cargo test: ✅ pass
• integration tests: ✅ 127 passed
• public-api check: ❌ fails (InnerMap removed from API)

Why it fails:
InnerMap is used as a trait bound on public types:

pub struct ArrayOfMaps<T: InnerMap> { ... }

A private trait in a public bound triggers private_bounds, which becomes an error with -D warnings.

Conclusion:
pub is required to pass CI. The unsafe marker already discourages external implementations, and the kernel validates map types at load time anyway.

@tamird partially reviewed 42 files, made 8 comments, and resolved 1 discussion.
Reviewable status: 19 of 43 files reviewed, 8 unresolved discussions (waiting on @Brskt).

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

I see. This should be a sealed trait then since we don't want external implementations.

-- commits line 25 at r38:
this commit is ...bad. it's adding a bunch of code that is unused, making review impossible.

ebpf/aya-ebpf/src/maps/hash_of_maps.rs line 14 at r36 (raw file):

pub struct HashOfMaps<K, V> {
    def: UnsafeCell<bpf_map_def>,
    _k: PhantomData<K>,

See #1447; use a single phantom plz

aya-ebpf-macros/src/map.rs line 20 at r37 (raw file):

        let mut args = syn::parse2(attrs)?;
        let name = name_arg(&mut args).unwrap_or_else(|| item.ident.to_string());
        let inner = pop_string_arg(&mut args, "inner");

while you're here, please add err_on_unknown_args(args)?; (see #1448)

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

                #[used]
                static #binding_ident: [u8; #binding_len] = [#(#binding_bytes),*];
            }

are we following libbpf conventions here? needs citations

Code quote:

            // Create a unique identifier for the binding
            let binding_ident = format_ident!("__inner_map_binding_{}", name);
            // Format: "outer_name\0inner_name\0" (null-terminated strings)
            let binding_value = format!("{}\0{}\0", name, inner);
            let binding_len = binding_value.len();
            let binding_bytes = binding_value.as_bytes();
            quote! {
                #[unsafe(link_section = ".maps.inner")]
                #[used]
                static #binding_ident: [u8; #binding_len] = [#(#binding_bytes),*];
            }

aya-ebpf-macros/src/map.rs line 42 at r37 (raw file):

            }
        } else {
            quote! {}

we can drop this b/c Options impls ToTokens

https://docs.rs/quote/latest/quote/trait.ToTokens.html#impl-ToTokens-for-Option%3CT%3E

aya-ebpf-macros/src/map.rs line 118 at r37 (raw file):

        );
        // "OUTER\0INNER_TEMPLATE\0" = 21 bytes
        assert!(expanded_str.contains("21usize"), "expected 21 bytes");

these assertions are problematic because they emit no information on failure

Code quote:

        assert!(
            expanded_str.contains(".maps.inner"),
            "expected .maps.inner section"
        );
        assert!(
            expanded_str.contains("__inner_map_binding_OUTER"),
            "expected binding identifier"
        );
        // "OUTER\0INNER_TEMPLATE\0" = 21 bytes
        assert!(expanded_str.contains("21usize"), "expected 21 bytes");

ebpf/aya-ebpf/src/maps/array_of_maps.rs line 19 at r36 (raw file):

unsafe impl<T: InnerMap> Sync for ArrayOfMaps<T> {}

impl<T: InnerMap> ArrayOfMaps<T> {

let's reduce some of this boilerplate, see #1447

@Brskt made 8 comments.
Reviewable status: 19 of 43 files reviewed, 8 unresolved discussions (waiting on @tamird).

-- commits line 25 at r38:

Done, is this the way u wanted ?

aya-ebpf-macros/src/map.rs line 20 at r37 (raw file):

Done.

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

No, this is not following libbpf conventions. Documentation has been added to clarify this.

libbpf uses BTF relocations within the .maps section for inner map bindings (see https://patchwork.ozlabs.org/comment/2418417/), where u declare .values = { [0] = &inner_map, ... } and libbpf processes the relocations.

The .maps.inner section is an aya-specific mechanism. This approach was chosen because:

• aya-ebpf doesn't require BTF for map definitions
• It provides a simpler mechanism that works with both legacy and BTF-style maps

The format is now documented in both aya-ebpf-macros/src/map.rs and aya-obj/src/obj.rs with references to the libbpf implementation.

aya-ebpf-macros/src/map.rs line 42 at r37 (raw file):

Done.

aya-ebpf-macros/src/map.rs line 118 at r37 (raw file):

Done.

ebpf/aya-ebpf/src/maps/array_of_maps.rs line 19 at r36 (raw file):

Acknowledged. This PR can be rebased on top of #1447 once it's merged to use the MapDef abstraction, which will eliminate the duplicated UnsafeCell<bpf_map_def> wrapper, unsafe impl Sync, and constructor boilerplate.

Should I wait for #1447 to land first, or would you prefer I implement a similar pattern in this PR?

ebpf/aya-ebpf/src/maps/hash_of_maps.rs line 14 at r36 (raw file):

Done.

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

Done.

Each map type now implements Sealed (e.g., impl<T> Sealed for Array<T> {}), preventing external implementations while keeping InnerMap public to satisfy the trait bounds on ArrayOfMaps<T: InnerMap> and HashOfMaps<K, V: InnerMap>.

@tamird partially reviewed 26 files, made 3 comments, and resolved 3 discussions.
Reviewable status: 3 of 43 files reviewed, 7 unresolved discussions (waiting on @Brskt).

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

Doesn't this mean that libbpf can't load aya programs that use map-in-map, and vice versa? That's generally not the approach we have taken.

A better link: torvalds/linux@646f02ffdd49

aya-ebpf-macros/src/map.rs line 106 at r47 (raw file):

    #[test]
    fn test_map_with_inner() {

the tests above check for the exact generated code, can we follow the same style? if not, please add a comment explaining why

aya-ebpf-macros/src/map.rs line 171 at r47 (raw file):

            ),
        );
        assert!(result.is_err());

pretty weak assertion

@Brskt made 3 comments.
Reviewable status: 2 of 48 files reviewed, 7 unresolved discussions (waiting on @tamird).

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

Done. #[btf_map] with btf_maps::ArrayOfMaps/HashOfMaps now works with both aya and libbpf loaders (tested both). Uses [*const V; 0] for the values field per the BTF relocation format libbpf expects.

Legacy #[map(inner = "...")] remains aya-specific but is now documented as such.

Does this address your concern ?

aya-ebpf-macros/src/map.rs line 106 at r47 (raw file):

Done.

aya-ebpf-macros/src/map.rs line 171 at r47 (raw file):

Done.

@tamird partially reviewed 41 files and made 2 comments.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @Brskt).

ebpf/aya-ebpf/src/btf_maps/array.rs line 11 at r53 (raw file):

///
/// This map type stores elements of type `T` indexed by `u32` keys.
/// The struct layout is designed to be compatible with both aya and libbpf loaders.

what does that mean?

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

#[repr(C)]
#[allow(dead_code)]
pub struct Array<T, const M: usize, const F: usize = 0> {

why did we need to toss bpf_map_def!?

@Brskt made 2 comments.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @tamird).

ebpf/aya-ebpf/src/btf_maps/array.rs line 11 at r53 (raw file):

I've improved the comments. Is it clearer now ?

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

The existing btf_maps that use btf_map_def! (RingBuf, SkStorage) aren't libbpf-compatible either - they only work with aya's loader. For this PR, you requested that map-of-maps be loadable by both aya and libbpf, so I used flat #[repr(C)] structs instead.

@tamird made 1 comment.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @Brskt).

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

Ah, yeah this is also #1455. Would you be willing to send a separate PR to fix that for all the maps?

@Brskt made 1 comment.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @tamird and @vadorovsky).

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

Done in #1457

@Brskt made 22 comments.
Reviewable status: 17 of 50 files reviewed, 22 unresolved discussions (waiting on @tamird and @vadorovsky).

aya/src/bpf.rs line 130 at r102 (raw file):

I renamed to pending_prog_array_inserts. if this better for you.

aya/src/bpf.rs line 224 at r102 (raw file):

Done.

aya/src/bpf.rs line 247 at r102 (raw file):

Yikes, this is unrelated to map-of-maps. Removed it entirely.

aya/src/bpf.rs line 542 at r102 (raw file):

Done.

aya/src/bpf.rs line 564 at r102 (raw file):

Yeah that heuristic was nonsense, replaced it with an explicit error if no inner binding is provided.

aya/src/bpf.rs line 566 at r102 (raw file):

The kernel needs inner_map_fd when creating a map-of-maps, so we create regular maps first. Updated the comment.

aya/src/bpf.rs line 656 at r102 (raw file):

Unified into a single loop using chain(). The only difference is resolving inner_map_fd for map-of-maps, None for the rest.

aya/src/bpf.rs line 862 at r102 (raw file):

Removed.

aya/src/maps/mod.rs line 107 at r102 (raw file):

Yeah fair enough, replaced with MapError::MissingInnerMapBinding.

aya/src/maps/array/array.rs line 97 at r102 (raw file):

It needs T = MapData concretely since create constructs an owned map via the syscall (the equivalent of bpf_map_create() in libbpf for dynamically creating inner maps at runtime). Can't go in the generic T: Borrow<MapData> block.

aya/src/maps/hash_map/hash_map.rs line 104 at r102 (raw file):

Same as above.

aya/src/maps/of_maps/array.rs line 15 at r102 (raw file):

Done.

aya/src/maps/of_maps/array.rs line 60 at r102 (raw file):

You're right, we don't. get() got rewored to be generic over M: FromMapData so the caller picks the inner map type. Validation still happens at runtime through each map's constructor. Applied the same to HashMapOfMaps::get() and the iterators.

aya/src/maps/of_maps/array.rs line 89 at r102 (raw file):

Right, for arrays you can just iterate by index with get(). Removed it.

aya/src/maps/of_maps/hash_map.rs line 13 at r102 (raw file):

Done.

aya/src/maps/of_maps/hash_map.rs line 47 at r102 (raw file):

Done with the get() generic.

aya/src/maps/of_maps/hash_map.rs line 76 at r102 (raw file):

After some research, yup, we can drop iter() and the iterator type. Kept keys() though since it's just generic BPF_MAP_GET_NEXT_KEY iteration and it's the only way to discover existing keys in the map.

aya/src/maps/of_maps/mod.rs line 1 at r102 (raw file):

Done.

aya/src/sys/bpf.rs line 599 at r102 (raw file):

Removed.

ebpf/aya-ebpf/src/btf_maps/mod.rs line 48 at r96 (raw file):

Restored.

ebpf/aya-ebpf/src/btf_maps/mod.rs line 126 at r96 (raw file):

No it didn't, moved it back. Whitespace restored too.

aya/src/programs/mod.rs line 128 at r102 (raw file):

Done.

@tamird reviewed 29 files and all commit messages, made 11 comments, and resolved 22 discussions.
Reviewable status: 42 of 51 files reviewed, 11 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/bpf.rs line 130 at r102 (raw file):

Looks like it's just removed. Great.

aya/src/bpf.rs line 530 at r108 (raw file):

        // Create regular maps first, then map-of-maps. The kernel requires
        // inner_map_fd when creating map-of-maps, so inner maps must exist first.

can you word this better? it's repeating the comment above in large part. this is classic LLM slop =/

Code quote:

        // Create regular maps first, then map-of-maps. The kernel requires
        // inner_map_fd when creating map-of-maps, so inner maps must exist first.

aya/src/bpf.rs line 554 at r108 (raw file):

            let btf_fd = btf_fd.as_deref().map(|fd| fd.as_fd());

            // For BTF map-of-maps, create a temporary inner map from the definition

how do you know if it's a BTF map-of-maps or not?

aya/src/bpf.rs line 557 at r108 (raw file):

            // embedded in the `values` BTF field. The temp map provides the fd that the
            // kernel needs during outer map creation; it is dropped afterwards.
            let btf_inner_map = if is_map_of_maps(map_type) {

this is a weird check -- you know this is true for maps_of_maps

you can do

for ((name, mut map_obj), is_map_of_maps) in regular_maps.into_iter().zip(iter::repeat(false)).chain(....zip(repeat(true))

aya/src/maps/mod.rs line 117 at r108 (raw file):

mod sealed {
    #[expect(unnameable_types, reason = "intentionally unnameable sealed trait")]
    pub trait Sealed {}

since this is the trait you end up implementing, it should have a descriptive name

blanket impl for the outer trait over the sealed trait completes the pattern

aya/src/maps/array/array.rs line 116 at r108 (raw file):

    /// # Ok::<(), aya::maps::MapError>(())
    /// ```
    pub fn create(max_entries: u32, flags: u32) -> Result<Self, MapError> {

does this need to be pub? ditto below

aya/src/maps/hash_map/hash_map.rs line 123 at r108 (raw file):

    /// # Ok::<(), aya::maps::MapError>(())
    /// ```
    pub fn create(max_entries: u32, flags: u32) -> Result<Self, MapError> {

do these need to be pub?

also, won't we need these additions for every inner map type? i'm surprised only array and hashmap are getting them. what am i missing?

aya/src/maps/of_maps/array.rs line 85 at r108 (raw file):

    /// Returns [`MapError::OutOfBounds`] if `index` is out of bounds, [`MapError::SyscallError`]
    /// if `bpf_map_update_elem` fails.
    pub fn set(&mut self, index: u32, value: &MapFd, flags: u64) -> Result<(), MapError> {

allowing an arbitrary mapfd here seems bad?

aya/src/maps/of_maps/array.rs line 109 at r108 (raw file):

        self.inner.fd()
    }
}

do these need to be pub?

Code quote:

impl ArrayOfMaps<MapData> {
    /// Returns a reference to the underlying [`MapData`].
    pub const fn map_data(&self) -> &MapData {
        &self.inner
    }

    /// Returns a file descriptor reference to the underlying map.
    pub const fn fd(&self) -> &MapFd {
        self.inner.fd()
    }
}

aya/src/maps/of_maps/hash_map.rs line 76 at r108 (raw file):

        &mut self,
        key: impl Borrow<K>,
        value: &MapFd,

this seems wrong

aya/src/maps/of_maps/hash_map.rs line 103 at r108 (raw file):

        self.inner.fd()
    }
}

why pub?

Code quote:

impl<K: Pod> HashOfMaps<MapData, K> {
    /// Returns a reference to the underlying [`MapData`].
    pub const fn map_data(&self) -> &MapData {
        &self.inner
    }

    /// Returns a file descriptor reference to the underlying map.
    pub const fn fd(&self) -> &MapFd {
        self.inner.fd()
    }
}

@Brskt made 10 comments.
Reviewable status: 42 of 51 files reviewed, 11 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/bpf.rs line 530 at r108 (raw file):

Reworded, better?

aya/src/bpf.rs line 554 at r108 (raw file):

We don't actually, reworded the comment to reflect that.

aya/src/bpf.rs line 557 at r108 (raw file):

Thanks, done.

aya/src/maps/mod.rs line 117 at r108 (raw file):

Done. Renamed to sealed::FromMapData with the method, added blanket impl of the outer trait.

aya/src/maps/array/array.rs line 116 at r108 (raw file):

Yes, MapData::create is already pub but requires constructing an aya_obj::Map manually. Array::create/HashMap::create are typed convenience wrappers so users don't have to reach into aya-obj to create standalone inner maps.

aya/src/maps/hash_map/hash_map.rs line 123 at r108 (raw file):

Yes, moved both to macros in mod.rs. FromMapData now covers all types the kernel supports as inner maps, create() covers the data-map types (Array, PerCpuArray, HashMap, PerCpuHashMap, LpmTrie, BloomFilter, Queue, Stack). Made new_legacy pub in aya-obj and dropped the redundant new_hash/new_array wrappers.

aya/src/maps/of_maps/array.rs line 85 at r108 (raw file):

This is consistent with the rest of aya - ProgramArray::set() accepts any &ProgramFd, SockMap accepts any AsRawFd. The kernel already validates compatibility at insertion time and returns EINVAL if the inner map doesn't match, so we're safe here.

aya/src/maps/of_maps/array.rs line 109 at r108 (raw file):

Yes - same pattern as Array, HashMap, and other map types. fd() is needed so users can e.g. pin the map, and map_data() gives access to the underlying metadata.

aya/src/maps/of_maps/hash_map.rs line 76 at r108 (raw file):

Same as above - consistent with the rest of aya, kernel validates at insertion time.

aya/src/maps/of_maps/hash_map.rs line 103 at r108 (raw file):

Same as ArrayOfMaps - consistent with Array, HashMap, and other map types.

@tamird reviewed 3 files and all commit messages, made 6 comments, and resolved 6 discussions.
Reviewable status: 40 of 51 files reviewed, 6 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/bpf.rs line 554 at r108 (raw file):

I still don't understand where this condition ("If this map-of-maps has a BTF values definition") is being evaluated

aya/src/maps/of_maps/array.rs line 85 at r108 (raw file):

I agree it's safe, but is there any reason not to validate at compile time? SockMap is hard because it's just an FD, I don't know the story with ProgramFd and ProgramArray but here it seems clear we can do better?

aya/src/maps/of_maps/array.rs line 109 at r108 (raw file):

Sorry, I'm not seeing it. Where is fd() on Array or HashMap? I do see a function called map that returns &MapData but it's part of the generic block on those maps and has a different name, so this doesn't look consistent to me.

aya/src/maps/of_maps/hash_map.rs line 76 at r108 (raw file):

But why would we do that? We know the type, why not check at compile time?

aya/src/maps/of_maps/hash_map.rs line 103 at r108 (raw file):

i don't think it is

aya/src/bpf.rs line 569 at r109 (raw file):

            let inner_map_fd = if is_map_of_maps {
                if let Some(inner) = &btf_inner_map {

this stack of checks makes no sense, btf_inner_map can only be Some if is_map_of_maps is true. so the outer check is useless

Code quote:

            let inner_map_fd = if is_map_of_maps {
                if let Some(inner) = &btf_inner_map {

@Brskt made 6 comments.
Reviewable status: 40 of 51 files reviewed, 6 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/bpf.rs line 554 at r108 (raw file):

Reworded.

aya/src/bpf.rs line 569 at r109 (raw file):

You're right, simplified.

aya/src/maps/of_maps/array.rs line 85 at r108 (raw file):

Done. set() and insert() now take &impl InnerMap where InnerMap is a sealed trait. Only map types the kernel supports as inner maps implement it. MapData and MapFd are also included as escape hatches.

aya/src/maps/of_maps/array.rs line 109 at r108 (raw file):

Sure, removed fd() and map_data() from Array and HashMap. ArrayOfMaps/HashOfMaps keep map_data() since they don't implement IterableMap.

aya/src/maps/of_maps/hash_map.rs line 76 at r108 (raw file):

Done.

aya/src/maps/of_maps/hash_map.rs line 103 at r108 (raw file):

Removed.

@tamird reviewed 6 files and all commit messages, made 3 comments, and resolved 3 discussions.
Reviewable status: 42 of 53 files reviewed, 4 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/maps/of_maps/array.rs line 85 at r108 (raw file):

But why that and not the specific map type? We know what T is, why can't we just use &T?

aya/src/maps/of_maps/array.rs line 109 at r108 (raw file):

you didn't remove map_data

aya/src/bpf.rs line 562 at r110 (raw file):

                    .inner()
                    .map(|inner| MapData::create(inner, &format!("{name}.inner"), btf_fd))
                    .transpose()?

ah i see what this is doing now. can we write

// The kernel ...
let inner_map = if is_map_of_maps {
  // Try using a BTF definition of the inner map.
  map_ob.inner().map(|inner| MapData::create(inner, &format!("{name}.inner"), btf_fd)).or_else(|| {
                    // No BTF inner definition; fall back to the `.maps.inner` binding.
                let inner_name = obj.inner_map_binding(&name).ok_or_else(|| {
                    EbpfError::MapError(MapError::MissingInnerMapBinding { name: name.clone() })
                })?;
                let inner_map = maps.get(inner_name).ok_or_else(|| {
                    EbpfError::MapError(MapError::InnerMapNotFound {
                        name: name.clone(),
                        inner_name: inner_name.to_owned(),
                    })
                })?;
                Ok(inner_map)
  }).transpose()?
} else {
  None
}

something like that?

Code quote:

                map_obj
                    .inner()
                    .map(|inner| MapData::create(inner, &format!("{name}.inner"), btf_fd))
                    .transpose()?

@Brskt made 3 comments.
Reviewable status: 42 of 53 files reviewed, 4 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/bpf.rs line 562 at r110 (raw file):

Done. Used if let instead of or_else since the BTF path produces an owned MapData (for lifetime) while the fallback borrows from maps.

aya/src/maps/of_maps/array.rs line 85 at r108 (raw file):

Yup, we can. Added V type parameter, set()/insert() now take &V instead of &impl InnerMap.

aya/src/maps/of_maps/array.rs line 109 at r108 (raw file):

Done, removed.

@tamird reviewed 23 files and all commit messages, made 10 comments, and resolved 3 discussions.
Reviewable status: 43 of 53 files reviewed, 11 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/bpf.rs line 539 at r96 (raw file):

                            .unwrap_or_else(|| Path::new("/sys/fs/bpf"));
                        let path = path.join(&name);

nit: restore

aya/src/maps/ring_buf.rs line 115 at r111 (raw file):

impl RingBuf<MapData> {
    pub(crate) const fn map_fd(&self) -> &MapFd {

why do you need this? most of our maps already define fn map(&self) -> &MapData { which we should probably centralize and then just use to get the FD. I am confused by all the new code that seems to duplicate existing functionality.

aya/src/maps/of_maps/array.rs line 64 at r111 (raw file):

    ///
    /// The inner map type `V` is determined by the type parameter on the
    /// `ArrayOfMaps` itself. Use `MapData` to retrieve an untyped handle.

why are we telling folks how to get an untyped handle?

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

        let map = new_map(test_utils::new_obj_map::<u8>(BPF_MAP_TYPE_ARRAY_OF_MAPS));
        assert_matches!(
            ArrayOfMaps::<_, MapData>::new(&map),

this is the default value of the parameter, is it needed? here and everywhere

aya/src/maps/of_maps/array.rs line 251 at r111 (raw file):

    fn test_get_not_found() {
        let map = new_map(new_obj_map());
        let arr: ArrayOfMaps<_> = ArrayOfMaps::new(&map).unwrap();

why do you need this ascription?

aya/src/maps/of_maps/hash_map.rs line 60 at r111 (raw file):

    ///
    /// The inner map type `V` is determined by the type parameter on the
    /// `HashOfMaps` itself. Use `MapData` to retrieve an untyped handle.

ditto

aya/src/maps/of_maps/hash_map.rs line 172 at r111 (raw file):

            aya_obj::generated::bpf_map_type::BPF_MAP_TYPE_HASH,
        ));
        let mut hm: HashOfMaps<_, u32, MapData> = HashOfMaps::new(&mut map).unwrap();

same question here about all the unnecessary ascription

aya/src/maps/perf/perf_event_array.rs line 187 at r111 (raw file):

impl PerfEventArray<MapData> {
    pub(crate) fn map_fd(&self) -> &MapFd {

same as the ring_buf comment

ebpf/aya-ebpf/src/maps/mod.rs line 79 at r111 (raw file):

}

macro_rules! impl_private_map {

unclear how much this macro helps, though if you move fn map into it, that would be nice (see other comments)

ebpf/aya-ebpf/src/maps/mod.rs line 149 at r111 (raw file):